bundle: record auto-migration compatibility telemetry on deploy#5439
bundle: record auto-migration compatibility telemetry on deploy#5439shreyas-goenka wants to merge 1 commit into
Conversation
60fba4e to
cc47397
Compare
e7e9e83 to
7c783aa
Compare
|
Commit: 4412358
24 interesting tests: 15 SKIP, 7 KNOWN, 2 flaky
Top 28 slowest tests (at least 2 minutes):
|
cc47397 to
b2c7271
Compare
7c783aa to
5e587f0
Compare
b2c7271 to
c2aa303
Compare
5e587f0 to
2cd3ef3
Compare
c2aa303 to
b1d732b
Compare
2cd3ef3 to
07abec1
Compare
b1d732b to
9e2f26b
Compare
07abec1 to
26c3380
Compare
9e2f26b to
00c5b7b
Compare
26c3380 to
30172b5
Compare
00c5b7b to
addcb6a
Compare
30172b5 to
3646391
Compare
bf9f878 to
abe3dfb
Compare
| has_serverless_compute true | ||
| local.cache.attempt true | ||
| local.cache.miss true | ||
| permissions_section_is_set false |
There was a problem hiding this comment.
Because permissions are not set here, by definition state_path_acl_exceeds_permissions is true.
There was a problem hiding this comment.
Analysis needs to take this into account when looking at state_path_acl_exceeds_permissions.
Can we choose to not emit it when permissions are not set?
There was a problem hiding this comment.
Simpliefied. We only record a single is_auto_migration_compatible. All the rich logic lives in the CLI.
permissions block.
Approval status: pending
|
abe3dfb to
3c6a454
Compare
3c6a454 to
681e089
Compare
| has_serverless_compute true | ||
| local.cache.attempt true | ||
| local.cache.miss true | ||
| permissions_section_is_set false |
There was a problem hiding this comment.
Analysis needs to take this into account when looking at state_path_acl_exceeds_permissions.
Can we choose to not emit it when permissions are not set?
681e089 to
e6521fb
Compare
|
We will also track auto migration from terraform to direct, can we prefix these values with dms_ to disambiguate? I'd also use shorter names with the same prefix for grouping / easier search in telemetry dashboard. For example, instead of use: dms_compat_auto |
Deploying a bundle requires write access (CAN_EDIT or higher) to the state folder; after an automatic DMS migration that is governed by a deployment object carrying only the bundle's statically declared permissions. Migration is therefore seamless only when everyone with write access to the state folder is declared with CAN_MANAGE in the permissions section — anyone missing loses the ability to deploy. ApplyWorkspaceRootPermissions already calls SetPermissions on each workspace path prefix during deploy; the response carries the folder's resulting ACL, which we reuse (no extra API call) to evaluate this. Exactly one verdict is recorded per deploy: - is_definitely_auto_migration_compatible: everyone with write access to the state folder is statically declared. - is_not_auto_migration_compatible: the state folder has undeclared write access. Includes the statically known cases: /Workspace/Shared without group_name: users CAN_MANAGE, and a folder under /Workspace/Users/<owner> (the owner always has CAN_MANAGE) with no permissions section. - is_maybe_auto_migration_compatible: no permissions section and the state folder has no known write access; resolving it needs a GetPermissions call. The fake test server now models directory ACL inheritance (home-folder owners and ancestor folder grants appear as inherited entries), so the acceptance test exercises the full matrix via bundle paths, declared permissions, and real parent folder grants. Co-authored-by: Shreyas Goenka <shreyas.goenka@databricks.com>
|
Renamed per @denik's suggestion: the three verdict keys are now |
| // not declared in perms with CAN_MANAGE, the only declarable level that grants write | ||
| // access. Read-only folder access does not need to be declared. | ||
| func (p WorkspacePathPermissions) HasUndeclaredWriters(perms []resources.Permission) bool { | ||
| for _, wp := range p.Permissions { |
There was a problem hiding this comment.
How is this different from containsAll in the function above?
I.e. does it not care about readers?
If so, we can filter out readers and then call containsAll like above to keep the logic simple.
| } | ||
| return false | ||
| } | ||
|
|
There was a problem hiding this comment.
Please add a unit test for this to cover all cases and check that it matches what you need it to do.
| // Whether workspace.state_path is under /Workspace/Shared. | ||
| StatePathIsShared = "state_path_is_shared" | ||
|
|
||
| // Whether this deploy is compatible with an automatic DMS migration. Deploying a |
There was a problem hiding this comment.
"DMS migration" sounds ominous (here and in the PR summary). We can be more verbose about what this is: "automatic migration to a dedicated state storage service" or something.
| // giveAccessForWorkspaceRoot applies the bundle's top-level permissions to the | ||
| // workspace folders and returns the resulting permissions of the folder that holds | ||
| // the deployment state, or nil when no permissions are declared or that folder is in | ||
| // /Workspace/Shared (which is not synced). |
There was a problem hiding this comment.
These carve-outs make it hard to reason about this function in context.
If callers need access to any one of the folders, we can return a type with the applied permissions for each one of the paths we could care about.
For the /Shared case we can return a static permission object if we special-case it.
| func setPermissions(ctx context.Context, w workspace.WorkspaceInterface, path string, permissions []workspace.WorkspaceObjectAccessControlRequest) error { | ||
| // pathContains reports whether the workspace folder at parent is, or is an ancestor | ||
| // of, child. Empty paths are treated as a match because workspace paths are fully | ||
| // defaulted before deploy. Both paths are /Workspace-normalized by PrependWorkspacePrefix. |
| // If the folder is shared, then we don't need to set permissions since it's always set for all users and it's checked in mutators before. | ||
| if libraries.IsWorkspaceSharedPath(path) { | ||
| return nil | ||
| return nil, nil |
There was a problem hiding this comment.
If we return a static permission here we don't need to special case it for its callers.
| if stateFolderPerms == nil { | ||
| if strings.HasPrefix(statePath, "/Workspace/Users/") { | ||
| // The home owner has CAN_MANAGE and the bundle declares no permissions. | ||
| return metrics.DMSCompatNot |
There was a problem hiding this comment.
Why not?
A user deploying to their home directory and not specifying permissions should be compatible.
| return metrics.DMSCompatNot | ||
| } | ||
| // Not under a home: we cannot tell without a GetPermissions call. | ||
| return metrics.DMSCompatMaybe |
There was a problem hiding this comment.
This is the only maybe.
We can consider making a permission check somewhere (and even bail early if we can't write) and pass it here to make a definitive verdict. Not blocking, can be a follow up.
|
How does this take groups into account? |
Telemetry only. Deploying a bundle requires write access (CAN_EDIT or higher) to the state folder; after an auto DMS migration that is governed by a deployment object carrying only the bundle's statically declared
permissions. Migration is seamless only when everyone with write access to the state folder is declared with CAN_MANAGE — anyone missing loses the ability to deploy. Evaluated duringbundle deployby reusing the existingSetPermissionsresponse (no extra API call).Exactly one verdict per deploy (
bool_values):dms_compat_auto— all write access on the state folder is declared.dms_compat_not— undeclared write access exists. Includes the statically known cases:/Workspace/Sharedwithoutusers: CAN_MANAGE, and a folder under/Workspace/Users/<owner>(owner always has CAN_MANAGE) with no permissions section.dms_compat_maybe— no permissions section and no known write access; resolving needs aGetPermissionscall.Plus
state_path_is_shared.Tested by one acceptance test over the location × permissions matrix, including undeclared and declared CAN_EDIT grants; the fake server models directory ACL inheritance (home owners + ancestor grants), with parent grants set up via
workspace set-permissions.